I added these implementation notes to the JavaDoc in a few places. It's quite easy to not notice that some code written is a capturing lambda that will likely cause allocation. I suspect we were not consciously aware of that for this code before (I don't recall being aware of that in this part of the code).

We should come up with a way to make sure this doesn't regress. We have some tests that assert there were no allocations in some executed code. Perhaps we could do similar with these. Asserting no allocations is generally easier than asserting a specific number of bytes allocated, since that depends on the JVM and environment.

I added tests for this in a subsequent commit. From the non-public methods asserting no allocations worked fine, but to assert only the ID allocation from a public method required adding public API variants of existing API that takes a Tags instance to avoid calling Tags.of which may allocate before JIT optimizations.

Merging with the default histogram config was moved into getOrCreateMeter when the passed DistributionStatisticConfig is not null. I think I initially did this in an effort to get rid of references in the lambda body that would be captured. Since things ended up with the registry as a parameter, I'm not sure it matters where the code is; it should be the same either way (famous last words). I suppose it's a little less duplication to have it in getOrCreateMeter, but it makes the method body longer in a critical function, which may make it harder to read the code.

Separately, it occurs to me that the method defaultHistogramConfig() will most likely always return an equivalent instance but it builds and merges it every time in most implementations. This is wasteful and could likely be improved. It only affects new meters, but it's still wasteful if it's always returning an equivalent config. I did at one point try one naive approach which didn't work, so it can be left as future work to be considered.

This adapting of the BiFunction to NewMeterSupplier is a capturing lambda that allocates (it did before these changes too), which is why we avoid calling this variant of registerMeterIfNecessary from the Counter call stack. It's convenient though, so we still use it for Function meters that should only ever be registered once anyway.

We take the pause detector as a parameter here so we don't need to capture it in the lambda for the NewMeterSupplier (previously the BiFunction).

This was added to avoid the Tags.of call when we already have a Tags instance. After JIT warm-up, it should not make any difference, but until then, calls to Tags.of with a Tags instance can allocate an ArrayIterator. This was an issue in the added unit test where JIT will not have eliminated that allocation.

Originally I left this with the builder to prove the point that JIT can eliminate the apparent allocation that was here. While that's still true, this change along with the new counter method that takes a Tags parameter avoids some allocations even before JIT optimizes. This was useful for the added unit test asserting allocated bytes, where JIT won't have optimized the code. It also helps reduce allocation in applications before JIT optimization (e.g. start-up or low traffic applications).

We could make this added API (and the equivalent counter/ltt API) non-public if we don't want to add API that's mostly sugar which could overwhelm users with options, but it seems harmless enough, and as mentioned in another comment, there are cases it can improve performance before JIT optimization.